One form of electronic funds transfer (“EFT”) currently used domestically is known as direct payment or direct deposit instruments (hereinafter generally referred to as “direct payment”). A direct payment instrument is an electronically transmitted instruction to credit or debit a particular account. For example, a company can use direct payment to credit the accounts of its employees, customers, vendors, and beneficiaries. Direct payment instruments are becoming increasingly popular as conventional payment methods, such as checks, decrease in popularity. Because the transaction is performed electronically, direct payment instruments offer convenience and reliability. An electronic system that supports direct payment instruments in the United States is referred to as the Automated Clearing House (“ACH”).
The ACH is a nationwide system supported by several operators, including the Federal Reserve Banks and other institutions. The ACH network is governed by a set of rules administered by the National Automated Clearing House Association (“NACHA”). The ACH network provides clearing of generally small value, repetitive and one-time payments among banks that participate in the ACH network. Financial institutions collect transactions and package them in batched ACH files according to the NACHA rules for forwarding to other institutions via the ACH network.
The ACH is a payments mechanism that replaces paper payments with electronic transactions and provides a more cost-effective and efficient alternative to writing, collecting, and processing paper checks, typically for recurring payments of small dollar amounts. ACH transactions are processed through the ACH network, a nationwide, batch-oriented electronic funds transfer system governed by the ACH rules. The ACH network provides for the inter-bank clearing of electronic payments (credits and debits) for participating financial institutions.
ACH offers financial institutions, companies, consumers, and others an efficient, alternative payment method to writing, collecting, and processing paper checks. Throughout this specification, any reference to the term “company” is intended to be representative of the originator or receiver of electronic ACH entries and does not imply exclusion of other types of organizations. Transactions are created by an originator and are delivered to an originating depository financial institution (“ODFI”). The ODFI may act as their own sending point, or it may use a third party sending point, to electronically transmit the information in a file to an ACH operator. The ACH operator can comprise the Federal Reserve Banks or another entity.
The file comprises batches, and each batch represents a series of ACH transaction items pertaining to one originator and payment type. ACH transaction items are individual electronic debits or credits formatted to meet National Automated Clearing House Association (“NACHA”) standards. Once received by the ACH operator, the transaction items are sorted and prepared for delivery to a receiving depository financial institution (“RDFI”). The RDFI may act as its own receiving point, or it may use a third party receiving point, to electronically receive a file from the ACH operator. The ACH Operator may provide ACH accounting information in a machine-readable format to facilitate the automation of accounting information for participating DFIs.
The following provides definitions of the ACH system participants:
(1) ACH Operator: The Federal Reserve Banks or another operator which receives transaction items from an ODFI through its sending point, distributes the items to appropriate RDFIs or their third party processor(s), and performs the settlement functions (crediting and debiting of accounts) for the affected financial institutions. In some cases, operators may not perform the settlement function.
(2) Originator: A person or organization that agrees to initiate ACH entries into the payments system according to an arrangement with a receiver. The originator is usually a company that originates an ACH item to a consumer's account or another company's account. The originator is responsible for obtaining and retaining any required authorization from the receiver.
(3) Originating Depository Financial Institution (“ODFI”): A financial institution that receives the payment instructions from originators and forwards the items to the ACH operator.
(4) Receiver: A person or organization that has authorized an originator to initiate an ACH entry to the receiver's account at their RDFI.
(5) Receiving Depository Financial Institution (“RDFI”): A financial institution that receives ACH transactions from the ACH operator and posts them to the accounts of its customers (receivers).
(6) Receiving Point: The point to which files from the ACH operator are delivered for the RDFI. An RDFI may designate itself or another entity as the receiving point.
(7) Sending Point: The actual point from which a file is communicated to the ACH operator for the ODFI. The ODFI may designate itself or another entity as its sending point. The ODFI may have multiple sending points.
The following provides a description of the anatomy of an ACH file. ACH files comprise groups of ACH items in batches that must be in a specific sequence or the ACH operator will not process the file. Each ACH file has one file header, which primarily comprises immediate origin and destination information. Fields in the file header include the local ACH operator routing number, sending point or receiving point routing number, file date, file time, record block, destination name of the ACH operator, and origin name.
Each batch comprises one or more ACH items and contains a batch header record that identifies the originator and a batch control record. ACH files can comprise more than one batch. Depending on who creates the batch, either the ODFI or the originator will enter the data in the batch header. Fields in the batch header comprise the ODFI routing number, company name, company entry description (which prints on the customer statement), originator identification, batch number, effective entry date, and standard entry class code.
Each ACH batch also comprises a batch control record that announces the end of a batch. The batch control record comprises totals for the batch, such as number of items, total dollar amounts, and a summation (algorithm) of the RDFI identification. Each batch must have a control record before another batch can begin. Throughout this specification, reference to a batch header can comprise information from a batch control record.
Each ACH item comprises an item detail record. Fields in the item detail record comprise the dollar amount, the receiver's RDFI name and account number, the transaction code for the receiver's type of account, trace number, and RDFI routing number. Each item detail record must be constructed in accordance with the NACHA record layout according to the Standard Entry Class Code of the batch.
Each ACH file also comprises a file control record at the end of the last batch in the ACH file. The file control record announces the end of the file and includes a summary of all of the batch control records. Throughout this specification, reference to a file header can comprise information from a file control record.
Each file header identifies the immediate origin (sending point or ACH operator) and destination (receiving point or ACH operator). A file may comprise batches and items for one or more ODFIs. A file can comprise items for numerous RDFIs. Each batch comprises only one company's items. Input batches, which are being sent to the ACH operator by the ODFI, can comprise items for multiple RDFIs. Output batches, which are coming from the ACH operator, comprise items for only one RDFI.
In a conventional ACH system, a sending customer (the party communicating the file to the ACH operator), such as an ODFI, accesses a DOS terminal or uses a vendor supplied origination package to create an ACH file. The ACH file comprises at least one ACH batch comprising at least one ACH item. After creating the file, the sending customer (the party communicating the file to the ACH operator) confirms the credit and debit transaction totals in the created file. Then, an approving employee approves the created file for transfer to the ACH operator.
After approving the file, the sending customer establishes a direct connection between the DOS terminal and a mainframe computer at the ACH operator and communicates the ACH file to the mainframe computer. The mainframe computer does not acknowledge receipt of the ACH file.
The mainframe computer determines if it will accept the ACH file for further processing and settlement. To determine whether to accept the ACH file, the mainframe computer examines the file header information to determine if it conforms to the NACHA required format and content. If the file header information conforms to the required information, then the mainframe computer accepts the file. In that case, the mainframe computer performs a similar examination of each batch header in the file to determine whether to accept the respective batches. If the batch header information conforms to the required information, then the mainframe computer accepts the respective batch. Then, the mainframe computer examines the item detail record for each item in the accepted batches to determine whether it conforms to the required information. If yes, then the mainframe computer accepts the respective items. The mainframe computer then settles the accepted ACH items by debiting and crediting the appropriate accounts.
If the file header, batch header, or item detail record do not conform to the required information, then the mainframe computer rejects the respective file, batch, or item. In that case, the mainframe computer will not settle the rejected batches or files and will adjust the settlement on rejected items. Accordingly, the sending customer must correct the errors in the information and resubmit the rejected file, batch, or item in a new file for acceptance.
In the conventional system, the sending customer cannot obtain the status of files, batches, or items until the mainframe computer attempts to process each file, batch, or item. Periodically, the mainframe computer will generate a report for the sending customer to indicate the status of received ACH files, and the sending customer can login and download the report. That status includes only “processed” (accepted), “pended” (held until the sending point is consulted), or “rejected.” For files that are pended or rejected, only a general description of the error is included. If a particular file has not been processed, then the sending customer will not receive any status information for that file. The sending customer does not receive any information for accepted batches or items. If the sending customer has specific information for a particular item, then the sending customer can request a status for the particular item through an item trace report. The item trace function is available only on items from the previous ten processing days.
Accordingly, the sending customer may not receive any status information for several hours after communicating the file to the operator. The sending customer cannot obtain the current status of batches and items communicated to the operator and cannot obtain a status history for each ACH file, batch, and item.
Furthermore, if a file, batch, or item is rejected, the sending customer receives only an error message. Then, the sending customer must interpret the error message, determine the location of the error in the header, and correct the error before resubmitting the rejected file, batch, or item. The mainframe computer does not provide information to assist the sending customer in identifying the location and nature of the error.
In the conventional system, an originator that submits ACH items to the operator via a third-party sending point cannot obtain status information for ACH batches of its ACH items. The originator can request and receive only a status of its ACH items communicated by the third party to the operator.
Finally, conventional systems have several deficiencies regarding initiating an ACH item return or notification of change (“NOC”). For example, a conventional interactive voice response (“IVR”) system can allow a customer to initiate an item-level return or NOC. However, the customer must input a trace number, dollar amount, and RDFI routing number for a particular item to initiate the item-level transaction. If the mainframe computer can identify the particular item that matches the trace number, then it describes that item to the customer. Then, the customer can approve the particular item for a return or NOC. After approval, the mainframe computer can derive a new item from the particular item and can generate a batch and file for the new item. However, the customer cannot search for an item based on multiple criteria, such as amount, routing number, process/settlement date, account number, and company/individual name. Additionally, the conventional mainframe computer cannot return multiple items for selection by the customer, and the customer cannot select multiple items to initiate multiple returns or NOCs. The conventional system also cannot initiate an item-level dishonored return or contested dishonored return.
Accordingly, a need exists in the art for a method and system for tracking and reporting automated clearing house transaction status. Particularly, a need exists in the art for tracking ACH file, batch, and item status during multiple ACH processing events and for allowing customers to access that status information in real time. A further need exists in the art for providing batch-level status information to originators that utilize a third-party sending point to communicate its ACH items to an ACH operator. A need also exists in the art for a method and system for easily identifying ACH file and batch header errors and item detail record errors for correction by a customer. Particularly, a need exists in the art for graphically depicting header errors in automated clearing house transactions.